chore(renovate): retire maint-51 in favor of pip-compile lockFileMaintenance - #2413

What & why

maint-51-dependency-refresh.yml ran uv pip compile --upgrade ... -o requirements.lock on a schedule (1st & 15th) to refresh the lock. Renovate's pip-compile manager is now enabled on requirements.lock (canary renovate.json #2411 + fleet preset #2406), so this is a duplicate refresher — and maint-51 had been failing every scheduled run since ~March (unsatisfiable pytest pin, fixed in #2404). Retire it in favor of the manager's lockFileMaintenance.

Verification of the --upgrade-in-header concern (the original worry)

The follow-up note in #2411 worried that maint-51's --upgrade would land in the committed lock header and either break Renovate's parser or mis-direct it into a mass upgrade. Both turn out not to be real, verified two ways:

1. uv omits --upgrade from the lock header. Compiling the exact maint-51 command with and without --upgrade produces byte-identical headers (uv 0.10.3): --upgrade is a one-time action flag, not part of the reproducible recorded command.
2. Renovate's pip-compile header parser (lib/modules/manager/pip-compile/common.ts): --upgrade/-U is not in the uv allowlist, and throwForUnknownOption would throw "Option --upgrade not supported (yet)" — i.e. it would skip managing the lock, never silently re-run a mass --upgrade. Per-dep bumps are scoped with --upgrade-package=<dep>==<ver> (artifacts.ts), so a mass upgrade is structurally impossible.

So the acute risk is a non-issue; this PR is the cleanup (eliminate the duplicate, long-broken refresher).

Why lockFileMaintenance is the right replacement

lib/modules/manager/pip-compile/index.ts:

export const supportsLockFileMaintenance = true;
export const defaultConfig = {
  managerFilePatterns: [],
  lockFileMaintenance: { enabled: true, branchTopic: 'pip-compile-refresh',
                         commitMessageAction: 'Refresh pip-compile outputs' },
};

The manager enables lockFileMaintenance by default (overriding Renovate's global enabled:false). On schedule it deletes the lock and recompiles from scratch (artifacts.ts isLockFileMaintenance branch) = the --upgrade equivalent, respecting source pins. No config change is needed — it's already live (weekly, default schedule).

maint-51's other steps are covered elsewhere

• scripts/sync_test_dependencies.py --verify → already runs in reusable-10-ci-python.yml on every PR.
• dev-tool pin alignment (sync_tool_versions --check) → enforced on schedule by maint-auto-update-pypi-versions.yml + maint-sync-env-from-pyproject.yml (--apply); maint-51's --check was a redundant defensive assertion.
• in-PR lock regen backstop → maint-dependabot-auto-lock.yml (renovate-aware).

Changes

• delete .github/workflows/maint-51-dependency-refresh.yml
• drop its EXPECTED_NAMES entry in tests/workflows/test_workflow_naming.py
• remove it from docs/ci/WORKFLOWS.md (required by the doc-link guard), docs/ci/WORKFLOW_SYSTEM.md, docs/WORKFLOW_GUIDE.md, DEPENDENCY_TESTING.md
• document lockFileMaintenance ownership in renovate.json (so a scheduled refresher isn't reintroduced)

Historical/dated docs (audits, transition plans, dated reviews) are left as point-in-time records.

Tests

tests/workflows/ — 685 passed, 3 skipped locally (naming, inventory-parity, and doc-link-resolve guards all green). renovate.json validates as JSON.

Follow-ups (out of scope — fleet promotion, per #2411)

• Consumer template templates/dependency-refresh.yml + its mention in templates/consumer-repo/WORKFLOW_USER_GUIDE.md should be retired when the pip-compile block is promoted into renovate-presets/fleet.json and maint-69 is updated.
• Counter_Risk is the last repo still on Dependabot (blocked on its golden-CSV CI).

🤖 Generated with Claude Code

Summary by CodeRabbit

• Chores
  • Removed the scheduled dependency refresh workflow; dependency management is now handled through Renovate's pip-compile functionality.
  • Updated documentation and configuration references to reflect the simplified maintenance process.